Logic simulation is one of the most commonly used method for verifying circuit designs. It produces circuit signal values based on the current circuit state and inputs. More specifically, logic simulation takes a circuit design and the given input patterns to calculate values that will be produced by the design code. For example, logic simulation for an AND gate with inputs 0 and 1 will produce 0 on its output. Simulating the same gate with inputs 1 and 1 will produce 1 on its output.
Values produced by logic simulation can then be used to check whether the circuit behaves according to the specification. This is typically done using checkers to verify the correctness of the design. Checkers sample circuit signal values and then determine if the values are correct. Two common types of checkers are assertions and reactive testbenches. An assertion encodes logic relationships among signals using predefined logic rules. Testbenches are typically written using behavior code. Logic simulation is flexible and can handle various types of checkers like assertions and behavior testbench that can be reactive. However, for large designs logic simulation can be exceedingly slow.
Because logic simulation can take considerable time to perform for large designs, emulation has been designed to address this issue. Emulation uses FPGAs to implement the design in hardware, and it can produce signal values based on inputs and design states orders of magnitude faster than logic simulation. However, signal value visibility inside the emulator system is typically limited, and only the primary outputs of the design can be directly observed.
Checkers used in a design, such as assertions, typically only need access to a small number of circuit signals. Even though only a small number of signals is needed, generating those signals using logic simulation still requires simulating most if not the whole design, which is slow. Emulation can quickly generate values for those signals. However, extracting those values from emulation and then use them for the checkers is either difficult or time consuming.
To address this issue, some checkers may be synthesized and emulated with the rest of the design. However, in practice only a small number of checkers can be synthesized, and adding them to emulation impacts performance adversely. As a result, those checkers are typically not used in emulation environments, which greatly reduces the chance to find bugs using emulation and hurts final design quality.
Another way to address this issue is to obtain internal signal values in an emulated design and use those values on the checkers. One way to obtain internal signal values is to stop functional clocks and use scan chains to scan out flipflop values inside the design. This method can obtain most flipflop values without additional hardware added to the emulator. However, it can be exceedingly slow due to the large number of cycles needed to scan values out.
Dedicated hardware for obtaining emulation values can be used instead of scan chains to improve value collection speed. For example, one solution adds channels to monitor flipflop values and send the signals out to a logic analyzer. Such special hardware can provide better performance than using scan chain. However, dedicated hardware increases cost of the emulation system. Additionally, how to efficiently and easily replay the obtained logic values on the checkers remain a big challenge.